In the multi-worker branch, the import string points to runpod.serverless.modules.rp_fastapi:app, but this module does not define a module-level app symbol. Additionally, factory=True tells Uvicorn to treat that import as an app factory callable; even if app existed as a FastAPI instance, this would be invoked like a zero-arg function and fail. Define a proper module-level factory (and reference it), or expose a module-level ASGI app and remove factory=True so workers>1 can start reliably.

import uvicorn.workers is executed in both branches but the module isn’t used. Importing uvicorn.workers typically requires the optional gunicorn dependency; since this repo doesn’t declare gunicorn, this can raise ModuleNotFoundError and break even the single-worker path. Remove this import (or guard it behind an explicit optional dependency check if you truly need Gunicorn).

start_uvicorn now has branching behavior for api_concurrency > 1, but there are no unit tests asserting the parameters passed to uvicorn.run in either branch (especially the multi-worker import-string path). Adding targeted tests that patch runpod.serverless.modules.rp_fastapi.uvicorn.run and exercise both concurrency modes will help prevent regressions like missing symbols / wrong factory settings.

Enabling workers > 1 means requests will be served by multiple processes. JobsProgress persists to disk, but methods used by the API (job_list.get(...) in _sim_stream/_sim_status and others) don’t reload state before reading, so a worker may not see jobs added by a different worker and return “Job ID not found”. If multi-worker mode is supported, consider reloading state on reads (e.g., in JobsProgress.get() / __iter__) or otherwise ensuring cross-process consistency for job tracking.